home *** CD-ROM | disk | FTP | other *** search
/ Atari Mega Archive 1 / Atari Mega Archive - Volume 1.iso / lists / gem / l_1199 / 1175 < prev    next >
Encoding:
Internet Message Format  |  1994-08-27  |  9.4 KB
  1. From: Mark.Baker@mettav.exnet.com (Mark Baker)
  2. Date: 29 Jul 94  10:36:10
  3. Message-Id: <UUCP.775504910@mettav>
  4. Subject: Re: Digest
  5. To: gem-list@world.std.com (gem-list@world.std.com)
  6. Precedence: bulk
  7.  
  8. Ofir:
  9.  >> Looks like Ofir started a trend :)
  10.  >
  11.  > What trend?
  12.  
  13. Sending blank messages. There were two more after yours :)
  14.  
  15.  > Unless Atari release AES 4.1 to the public and continue development, MTOS
  16.  > is a waste of time. I'd love to multi-task on the Falcon, but MTOS is not
  17.  > reliable enough and is still very slow at disk access (I have the latest
  18.  
  19. The main problem is that it still uses the bios routines for disc access, which
  20. are blocking. There is a driver for the falcon's SCSI interface, and someone
  21. got minixfs to work with it to give non-blocking disc i/o. Really we need more
  22. device drivers and versions of minixfs and tosfs that use them, but this is
  23. probably quite a long way off.
  24.  
  25. Timothy:
  26.  > Where/When can I get the new version of MultiTOS?
  27.  
  28. You can't. Definitely not legally and I haven't seen illicit copies on any
  29. bulletin boards.
  30.  
  31. Evan:
  32.  > No, the code is not correct.  The assembly binding for Frename pushes
  33.  > a 0 on the stack instead of 86.  I believe this will terminate your
  34.  > program as opcode 0 is Pterm0() isn't it?  Yep, it is.
  35.  
  36. Lots of other bindings are wrong, particularly vdi ones. And nowhere does it
  37. mention that returns from gemdos, bios and xbios functions are in d0.
  38.  
  39.  > There are numerous others.  Ahh .. wind_set does not have the iconify
  40.  > options mentioned at all.  wind_get has them listed, but not wind_set.
  41.  
  42. They are mentioned in mine, which is the new version.
  43.  
  44.  > There are other problems.  You'd think after all this time that the
  45.  > idea of waiting for reverse mouse button event would be documented.
  46.  > evnt_multi barely mentions anything, other than see evnt_button,
  47.  > and evnt_button doesn't mention reverse events.
  48.  
  49. It mentions it now, but it's wrong! It says that it detects them
  50. independently, without mentioning the reversing of the state. And it ors 0x100
  51. to the mask not the number of clicks.
  52.  
  53.  > I bought mine used.  I better find out what in in this upgrade :-(
  54.  
  55. Lots of errors are fixed but there are still a _lot_ in it. Extra material
  56. -programming .xdd and .xfs drivers for MiNT, the xbra protocol, and extended
  57. style guide and memory map.
  58.  
  59. Warwick:
  60.  > Not just keyboard shortcuts, but general application defaults.
  61.  
  62. Yes.
  63.  
  64.  > Application-specific and `global' setting all in the one file.
  65.  
  66. No. Look at the windows win.ini file, which has application specific stuff.
  67. Every time you install an application it screws around with it and deinstalling
  68. an application is difficult as you don't know what it has changed. As a result
  69. new programs use separate settings files.
  70.  
  71.  > Format is "attribute_pattern: value", ie:
  72.  
  73. Fine.
  74.  
  75.  > An application, say `MyEdit', would search for matches to the attributes
  76.  > it is interested in.  For example, it would look for:
  77.  >
  78.  >  WordProcessor.MyEdit.FontSize
  79.  
  80. As I said I'm not happy with application specific stuff being in here.
  81.  
  82.  > A set of common attributes and application types needs to be decided.
  83.  > From there, we can create a APP_DEFS.SYS file that conforms to the
  84.  > shortcuts standard.
  85.  
  86. Yes. I don't object to application types, as word processors do need different
  87. shortcuts to drawing programs for example.
  88.  
  89.  > Multiple formats of the `value' should be supported.  For example, for
  90.  > key shortcuts, a standard notation like "^O" should be used by default
  91.  > app files, etc., but the user should be able to have a scancode if they
  92.  
  93. Yes, I prefer this to what someone suggested putting the ascii code or the
  94. scancode here.
  95.  
  96.  > have some key on there keyboard that is not one of the one available
  97.  > on all keyboards.  They'll have to provide a name for it in that case -
  98.  > so it can be described in a menu item.  eg. shift-< and shift->, Alt-
  99.  > number-pad-digit.
  100.  
  101. You can't have alt-num pad anyway as it's used for entering characters by their
  102. ascii code.
  103.  
  104.  >  Q: When windows are non-overlapping, how do you know where
  105.  >      your keypresses are going?
  106.  >  A: The top window is highlighted differently.
  107.  
  108. No, because you topped it.
  109.  
  110.  >  Q: So you can tell the focus by the window decorations?
  111.  >  A: Yes.
  112.  >  Q: So if I changed the appearance of the window with the focus,
  113.  >      you would have exactly that.
  114.  >
  115.  > This `change the appearance' could be changing the appearance of
  116.  > the cursor (ala TOSWIN and XTERM), and/or it could be changing the
  117.  > window colours.  On AES >=4.1 and under WINX, this can be done
  118.  
  119. AES >= 3.30 actually.
  120.  
  121.  >> cut and paste from text fields
  122.  >
  123.  > This I really miss on my machine at home, after using X11 all day at
  124.  > work.
  125.  
  126. LTMF does it in modal dialgues, and also any non-modal dialogues that use
  127. form_keybd/objc_edit. Of course if you use your own editable fields and they
  128. don't support it you can't really complain.
  129.  
  130. Timothy:
  131.  > I see no point in absolutely abandoning the GEM style.  It makes sense to
  132.  > make some modifications, yet some of the things you people are talking
  133.  > about like sending key-presses to a background window are not only hard
  134.  > to implement and counter-intuitive, but possibly DANGEROUS.  I will not
  135.  > send keypresses to a background window, and unless it's absolutely
  136.  > necessary, I don't see any point in sending mouse-clicks to a background
  137.  > window either.  It's just not GEM and it will only confuse and frustrate
  138.  > people.
  139.  
  140. I agree with you entirely here.
  141.  
  142.  > I am writing a window library.  At the present it is about 20k.  Already,
  143.  > it cuts userinterface development for me into a small fraction of the
  144.  > time it took before.  It sets things up for me, does amodal dialogs, and
  145.  > handles and directs window events automatically for me.  It also makes
  146.  > any application that runs under it a little more object oriented,
  147.  > treating each window as a seperate object and giving the application
  148.  > simple means to handle data independantly for each window.
  149.  >
  150.  > With that, I have to ask what is in some of these other libraries that
  151.  > take up over 200k?  Loads and loads of more features.... most of which
  152.  > someone looking to get work done would never use.
  153.  
  154. Firstly for particular types of windows such as images or text they handle it
  155. all for you. Secondly the dialogue handling includes progdefs to add more
  156. features such as CUA-style toggles and radio buttons.
  157.  
  158. And of course if you don't use the features your program won't grow that big.
  159.  
  160. Vincent:
  161.  > In your button code (very useful, thanks), you set the high byte of
  162.  > the second parameter. Is it a GEM feature or an accident? (The Atari
  163.  > Compendium doesn't say anything about it, nor the other books I have.)
  164.  
  165. That was the whole point of his code, to demonstrate an undocumented feature in
  166. the aes, namely that ORing 0x100 with the number of clicks will cause it to
  167. exit when the specified state is _not_ used, so you make the mask 0x03 and the
  168. state 0x00 then it will wait for the state not to be both up, ie either button
  169. down.
  170.  
  171. This is not in the first edition of TAC, it is documented totally wrongly in
  172. the second.
  173.  
  174. David:
  175.  > For keys, I think we need to formalise as many keys as are used in a wide
  176.  > number of applications. This means all of the keys that Atari/GemList
  177.  > specify, plus a few more if we can think of them.
  178.  
  179. All keys that will appear in more than one application doing the same thing,
  180. should be in it.
  181.  
  182.  > Other functions I think we need names for are:
  183.  >
  184.  > Dialogs in Windows (on/off)
  185.  > Novice User Help (on/off)
  186.  > Confirm on Exit/Save on Exit
  187.  > Auto Save Prefs on Exit
  188.  > Default Window Size (Lattice C really annoys me when every new window is
  189.  > full screen!)
  190.  
  191. I agree with all of these apart from the last, as this surely depends on what
  192. application it is.
  193.  
  194. Warwick:
  195.  > I know what you mean - I often double-click on a field, hoping it will
  196.  > give me a file selector.
  197.  >
  198.  > It's not really a problem:  older applications will still have the
  199.  > hidden feature, and newer/updated ones could have an icon that clearly
  200.  > indicates that double-clicking is not how to access the feature.  A
  201.  > standard icon could be chosen from the characters set.  ('*' in BOXCHAR?)
  202.  
  203. A problem with that is that if you are used to new applications which have an
  204. icon you will not expect the file selector to appear on older programs.
  205. Actually a lot of programs only use single clicks for the file selector ATM.
  206.  
  207. Dan/Ken:
  208.  >> I see no point in absolutely abandoning the GEM style.  It makes sense
  209.  >> to make some modifications, yet some of the things you people are
  210.  >> talking about like sending key-presses to a background window are not only
  211.  >> hard to implement and counter-intuitive, but possibly DANGEROUS.  I will
  212.  >> not send keypresses to a background window, and unless it's absolutely
  213.  > 
  214.  > Nobody should *ever* send keypresses to anything but the window under
  215.  > current focus. It is *incredibly* confusing to do otherwise. Just flip
  216.  > this option on in some X11 window manager and you'll learn really damn
  217.  > quick to hate it (as well as auto-window topping.. this is a totally
  218.  > STUPID idea!)
  219.  
  220. I never thought I'd say this, but I actually agree with you here :)
  221.  
  222.  > By the way, I'm not sure what you mean by 'abandoning the GEM style'.
  223.  > There really is none! There is almost no consistency in GEM user interfaces,
  224.  > the way things work under different versions of TOS, etc.
  225.  
  226. But there is a standard for what windows look like and what the gadgets do. Yes
  227. it depends on TOS version but people only use one TOS version and with that all
  228. their applications _except_those_written_with_your_library_ will look and feel
  229. the same.
  230.  
  231.  
  232.  
  233.